…ents as in-reactor

MavenResolutionResult.parentPomIsProjectPom() answers a GAV-only question:
"is the parent's GAV among the project poms?" Two POMs co-ingested into the
same LST (e.g. an external corp-parent and one of its independently-built
modules) match by GAV without sharing any actual Maven reactor, but the
scanner used the GAV match alone to route the child away from the orphan
branch — resulting in zero changes for the affected module.

Defer the routing decision until aggregator data has been collected, then
verify the parent-child link by walking aggregator <modules> chains. A link
counts only if the child is reachable via some aggregator's reactor BFS;
otherwise the child falls into the orphan branch and gets its own
build/plugins. Read aggregator membership from the requested (raw) Pom's
subprojects, since ResolvedPom.subprojects is unreliable in some LST
fixtures and mrr.getModules() lists POMs that declare *this* one as
their <parent> rather than ones aggregated by it.

Also:
- Skip dangling pom-packaging POMs (not claimed as parents, not aggregators)
  so coincidentally-ingested external parents don't get spurious
  build/plugins.
- Pass the source path as AddPluginVisitor's filePattern only for the
  reactor-broken-orphan case, so its own parentPomIsProjectPom() guard
  doesn't refuse to add the plugin.
- Simplify the reproducer test: drop the pre-declared maven-compiler-plugin
  on the child, since AddPluginVisitor does not currently fill in missing
  configuration on an existing plugin (a separate latent bug; not addressed
  in this commit).

…notationProcessorPaths

When the target POM pre-declares maven-compiler-plugin (e.g. just to set
<source>/<target>) but does not configure annotationProcessorPaths,
AddAnnotationProcessor produces zero changes today: AddPluginVisitor
short-circuits because the plugin already exists, and the inner visitor
only operates on existing <annotationProcessorPaths> tags.

Two new tests in SingleModuleProject reproduce the gap:

- addConfigurationToExistingPluginWithNoConfig — plugin declared with no
  <configuration> at all.
- addAnnotationProcessorPathsToExistingConfiguration — plugin has
  <configuration> with <source>/<target> but no annotationProcessorPaths.

Both expect the recipe to fill in the missing structure. Both fail on the
current main with "Recipe was expected to make a change but made no
changes." Fix follows in a separate commit.

…g maven-compiler-plugin

When the recipe target POM already declared maven-compiler-plugin (e.g.
solely to set <source>/<target>), AddPluginVisitor's "plugin already
exists" branch left the plugin untouched, and the path-adding inner
visitor only operated on existing <annotationProcessorPaths> tags — so
nothing got added. This is the second of the two bugs surfacing on top of
the GAV-coincidence orphan-detection issue.

Before invoking the path-adding visitor on the matched plugin, ensure
<configuration><annotationProcessorPaths/></configuration> exists. The
helper is conservative: it adds nothing when the structure is already
present, only fills in whichever level is missing.